…egl/libGLES_mali.so

the library specifically rejects the symlink on my phone /vendor/lib64/hw/vulkan.ums9230.so -> ../egl/libGLES_mali.so  because it is technically in a different name space . this is just laughable but this solves it.

i have no objection to this directory tree except drop the duplicate file. perhaps it would work if they linked to -> ../libGLES_mali.so instead . apparently /vendor/lib64/hw/ is a different name space from /vendor/lib64/abc and they specifically test that no files are links between them. must be some kind of mistake

/vendor/lib64/
├── egl
│   └── libGLES_mali.so
├── hw
│   └── vulkan.ums9230.so -> ../egl/libGLES_mali.so
├── libGLES_mali.so
├── libOpenCL.so.1.2 -> libGLES_mali.so

7 directories, 20 files

the two libGLES_mali.so are identical . it is a gigantic file that contains all of CL GL Vulkan. nothing seems to call vendor/lib64/libGLES_mali.so it has become orphaned stranded. a stale copy from the lack of links to it

 # GL is completely broken
speaking of open GL.... suddenly things become murky nothing makes any sense anymore. the file name would imply it directly support OpenGL ES at full speed. glmark can't find any native GL device but finds zink at horrible speed. maybe if i can get glmark2-es2 to work it would be close to Vulkan speed . glmark2-es2 and glmark2-egl fail entirely and hardly anyone seem especially interested in this to my surprise. it seems like an interesting problem I have sun all day and full battery. in the forest in Tasmania at the end of the summer. winter and rain is coming. as usual end of February beginning March week long rain just like home in August September . Vulkan is flawless but open GL all implementations are slow as a snail or broken

here are the internal dispatch drivers

tree /system/lib64|ack GL
├── libEGL.so
├── libGLESv1_CM.so
├── libGLESv2.so
├── libGLESv3.so

all versions of glmark find vendor/lib64/egl/libGLES_mali.so in strace but the only one that works (glx) also find the dispatch driver system/lib64/libGLESv3.so (a copy of libGLESv2.so ) perhaps that is the key to the mystery that egl can't find the right file. i have no idea how mesa is looking for drivers it is probably broken. for some reason the glx build use the system loader instead and it "works" with horrible frame rate

strace glmark2-es2 2>&1|ack "EGL|GLES|_mali"
openat(AT_FDCWD, "/data/data/com.termux/files/usr/lib/libEGL.so", O_RDONLY|O_CLOEXEC) = 4
newfstatat(AT_FDCWD, "/vendor/lib64/egl/libGLES_mali.so",
no sign of system/lib64/lib*GL*
dri2_dpy->fd_render_gpu >= 0" failed

strace glmark2 2>&1|ack "_mali|EGL|GLES"
newfstatat(AT_FDCWD, "/vendor/lib64/egl/libGLES_mali.so",
readlinkat(AT_FDCWD, "/proc/self/fd/28", "/system/lib64/libEGL.so",
readlinkat(AT_FDCWD, "/proc/self/fd/67", "/system/lib64/libGLESv3.so", 4096) = 26
GL_VERSION:     3.1 Mesa 24.3.4

this failed again

LD_PRELOAD=/system/lib64/libEGL.so glmark2-es2
LD_LIBRARY_PATH=/system/lib64 glmark2-egl
Error: eglGetDisplay() failed with error: 0x300c

this breaks the vulkan interface that provides the swap chain

LD_LIBRARY_PATH=$P/lib glmark2
(/data/data/com.termux/files/home/wsi-twaik/wsi/x11/swapchain.cpp:335)

 # fix angle dispatch from glvnd not the horrible virtual device

this runs without a flaw

LD_LIBRARY_PATH=$P/opt/angle-android/gl ~/demos/out/src/egl/opengl/eglinfo -p angle  -v

but this would not play ball even though strace showed it found the file . whatever i did i could not teach lib glvnd to find my angle drivers which was a disappointment thay would be better. hate ld preload and path

$P/share/glvnd/egl_vendor.d/angle.json
"library_path" : "libEGL_angle.so"

ln -s $P/opt/angle-android/gl/libEGL_angle.so $P/lib/libEGL_angle.so

the only reference to angle is from virtual GL and it has no interface to mesa.

apt rdepends angle-android                      Reverse Depends:
  Depends: virglrenderer-android

it is using epoxy to load the angle drivers which is equivalent to ld Library path without the epoxy patch

virgl_test_server_android --angle-gl

is equivalent to

LD_LIBRARY_PATH=$P/opt/angle-android/gl virgl_test_server --use-egl-surfaceless --use-gles

LIBGL_ALWAYS_SOFTWARE=1 GALLIUM
_DRIVER=virpipe garbage_app68

this can handle a hodge podge of apps that use ancient copy and paste cody with no clue what they are doing and only testing on NVIDIA drivers. dosbox and furmark for instance

the GLES lock in seems like a crutch because surface less report native open GL support . although angle does not so maybe it is doomed to fail . i don't know if there is any way to render the full GL specification with angle since it's only for browsers

eglinfo -v -p surfaceless

EGL_RENDERABLE_TYPE: opengl,opengles,opengles2
  EGL_SURFACE_TYPE: pbuffer

but someone has to fix the mesa dispatch for angle the virtual GL nonsense is BS. how could that possibly be better outside of an emulator when you can call the driver directly instead without any overhead.